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REMARKS 

This Amendment is filed in response to the final Office 
Action dated January 30, 2004, which has a shortened statutory 
period set to expire April 30, 2004. 

Phone Application Development Environment: General Overview 

Applicants teach a zero- footprint remotely hosted phone 
application development environment. Specification, page 4, 
lines 10-11. In this environment, a developer can use a 
standard computer (without any specialized software) and a 
telephone to develop sophisticated phone applications that use 
speech recognition and/or touch tone inputs to perform tasks, 
access web-based information, and/or perform commercial 
transactions. Specification, page 4, lines 11-15. 

For example, referring to Fig. 1, a developer could use 
computer 102 to register in the development environment, e.g. by 
identifying herself /himself to a web-based application on 
development platform web server 108. Specification, page 20, 
lines 3-5. Based on the identity of the developer, a call 
number is provided to the developer. Specification, page 20, 
lines 13-22. The developer can develop the phone application 
code using a URI or a scratchpad. Specification, page 22, lines 
3-5. 

The URI can serve as a reference or pointer to the actual 
application code for the phone application platform 110, e.g. 
application file 114 in web server 101. Specification, page 22, 
lines 12-13. The URI can be submitted to development platform 
web server 108 by clicking an HTML form submit button. 
Specification, page 22, lines 13-16. Scratchpad development can 
be performed in a browser associated with computer 102 and can 
include a text entry field. Specification, page 23, lines 9-11. 
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The scratchpad can be an HTML form element. Specification, page 
23 , line 12. 

At this point, the developer can make edits to the 
application file. Specification, page 21, lines 7-8. To assist 
the developer in this editing process, a call flow can be 
provided. Specification, page 24, line 21 to page 25, line 1. 
The call flow information tracks a flow of execution for a phone 
call. Specification, page 25, line 13. In other words, as a 
phone application transitions from a first state to a second 
state, that information is available to the developer while 
he/she is on the phone using the application. Specification, 
page 25, lines 6-7. Similarly, the results of speech 
recognition can be shown, thus the developer can distinguish 
between a speech recognition error and a program logic error 
easily. Specification, page 25, lines 8-9. 

As discussed in further detail below, the cited references 
do not teach Applicants' zero- footprint remotely hosted phone 
application development environment and thus do not provide the 
advantages of this environment. 

Burg And House Fail To Render Obvious Claims 1-2, 4-7, 9-22, and 
24-29 

Applicants respectfully submit that the cited references, 
either individually or in combination, fail to disclose or 
suggest Claim 1. Specifically, Claim 1, as amended, now recites 
in part, 

receiving the phone application code over 
the network interface from a remote computer via 
a development platform web server and using a web 
protocol... and 

presenting a call flow to the remote 
computer over the network interface via the 
development platform web server and using the web 
protocol, the call flow tracking a flow of 
execution for a phone call. 
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In contrast, Burg teaches a system that automatically 
translates a web on-line sales menu to an IVR menu (see Fig. 3 
of Burg). Col. 3, lines 6-7 and col. 5, line 64 to col. 7, line 
20. Fig. 3 of Burg teaches that URLs of a web page are 
systematically downloaded and analyzed to provide a web menu. 
Col. 5, line 64 to Col. 7, line 20. The system allows the 
operator an opportunity to verify the analysis by tracking 
through the web page and site to resolve questions on the 
analysis. Col. 7, lines 21-23. 

Once the operator is satisfied with the basic translation 
of the web menu architecture to IVR menu architecture, the 
system creates an IVR outline. Col. 7, line 24-26. During this 
process, the system generates voice prompts and desired IVR 
responses. Col. 7, lines 31-34. Using a computer and 
telephone, the operator can monitor the automated translation of 
the web menu structure to an IVR menu structure with prompts and 
responses. Col. 8, lines 13-16. 

Once the IVR menu structure, prompts, and responses are 
developed, the system has completed the initial translation. 
Col. 7, line 49-50. The system allows the operator to modify 
the proposed IVR structure and resolve questions. Col. 8, lines 
16-17. Specifically, the system allows the operator to test the 
IVR structure using the telephone and resolve problems by 
referring to the web menu structure on the computer. Col. 8, 
lines 21-24. 

Therefore, Burg teaches monitoring of the automatic 
translation and limited correction of problems/questions 
associated with this translation, but does not allow the 
operator to develop the phone application code itself. For 
example, Burg states that the operator can verify the 
translation by tracking through the web page and site to resolve 
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questions (col. 7, lines 21-23 and col. 8, lines 16-17). Burg 
states that the IVR structure can be tested using a telephone 
and a computer. Burg then explicitly states that problems 
encountered during testing can be resolved by referring to the 
web menu structure on the computer (col. 8, lines 21-24) . This 
web menu structure cannot be characterized as a call flow. 

Applicants' recited call flow, which is presented to the 
remote computer, supports development of a phone application 
code for a computer based phone application platform. Of 
importance, Applicants note that the Office Action fails to 
identify any such platform in Burg. 

As explicitly taught by Burg, web server 82 is registered 
as a homepage URL and includes the addresses of all URLs within 
the Web sales architecture. Col. 7, lines 59-62. Web server 82 
functions as the homepage URL and URL of all linked pages. Col. 
7, lines 62-64. The HTML documents and information in databases 
80 and 81 are associated with these URLs. Col. 7, lines 64-65. 

Notably, Burg also explicitly teaches that an IVR server 85 
is electronically linked to web server 82, thereby allowing 
direct exchange of information and commands between web server 
82 and IVR server 85. Col. 8, lines 4-8. Burg is silent as to 
where the translation of the web menu to IVR menu takes place. 
However, in the absence of any translation component in system 
7 9 (Fig. 5) , the transfer of commands between web server 82 and 
IVR server 85 would indicate that both web server 82 and IVR 
server 85 provide translation functions. 

If that is the case, then Burg fails to teach receiving the 
phone application code over the network interface from a remote 
computer via a development platform web server and using a web 
protocol. Applicants' recited computer based phone application 
platform advantageously uses only web protocols. 
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House fails to remedy the deficiency of Burg. 
Specifically, House teaches that a help desk computer can debug 
an application while a user interacts with that application. 
Col. 6, line 67 to Col. 7, line 1. Specifically, a help desk 
technician can set breakpoints in the source code and watch 
variables to assist the user in debugging the application. Col. 
7, lines 13-17. To set up this three-way communication, a 
development client, which is provided at the help desk machine, 
can generate a debug proxy file and provide this file to the 
user computer using a communication link. Col. 7, lines 36-42. 

Notably, House fails to teach anything regarding a phone 
application code, much less receiving the phone application code 
over the network interface from a remote computer via a 
development platform web server and using a web protocol. House 
also fails to teach presenting a call flow to the remote 
computer over the network interface via the development platform 
web server and using the web protocol, the call flow tracking a 
flow of execution, for a phone call. Therefore, House fails to 
remedy the deficiency of Burg. 

Because Burg and House, either individually or in 
combination, fail to disclose or suggest the limitations recited 
in Claim 1, Applicants request reconsideration and withdrawal of 
the rejection of Claim 1. 

Claims 2 and 4-6 depend from Claim 1 and therefore are 
patentable for at least the reasons presented for Claim 1. 
Based at least on those reasons, Applicants also request 
reconsideration and withdrawal of the rejection of Claims 2 and 
4-6. 

Claim 7, as amended, now recites in part: 

receiving the phone application code over 
the network interface from a remote computer via 
a development platform web server and using 
HTTP;... and 
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presenting a call flow to the remote 
computer over the network interface, the call 
flow tracking a flow of execution for a phone 
call . 

Applicants respectfully submit that Claim 7 is patentable 
for substantially the same reasons presented for Claim 1. 
Therefore, Applicants request reconsideration and withdrawal of 
the rejection of Claim 7. 

Claim 9 depends from Claim 7 and therefore is patentable 
for at least the reasons presented for Claim 7 . Based on those 
reasons, Applicants also request reconsideration and withdrawal 
of the rejection of Claim 9. 

Claim 10, as amended, now recites in part: 

receiving a reference to the phone 
application code over the network interface from 
a remote computer via a development platform web 
server and using a web protocol;... and 

presenting a call flow to the remote 
computer over the network interface via the 
development platform web server and using the web 
protocol, the call flow tracking a flow of 
execution for a phone call. 

Applicants respectfully submit that Claim 10 is patentable 
for substantially the same reasons presented for Claim 1. 
Therefore, Applicants request reconsideration and withdrawal of 
the rejection of Claim 10. 

Claims 11-14 depend from Claim 10 and therefore are 
patentable for at least the reasons presented for Claim 10. 
Based on those reasons, Applicants also request reconsideration 
and withdrawal of the rejection of Claims 11-14.. 

Claim 15, as amended, now recites in part: 

receiving over the web interface a uniform 
resource identifier (URI) from a second computer 
system, the URI corresponding to a location of a 
phone application; ...and 
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upon receiving a request from the second 
computer system on the first computer system, 
presenting to the second computer debugging 
information generated by calls to the telephone 
number for the phone application on the phone 
application platform, wherein the debugging 
information includes a flow of execution for the 
calls . 

Applicants respectfully submit that Claim 15 is patentable 
for substantially the same reasons presented for Claim 1. 

The Office Action cites col. 8, lines 34-43 as teaching the 
claim limitation "receiving over a web interface..." . However, 
this passage merely teaches that customers can access a web on- 
line service (with information stored in databases 101/102) 
using various computers and an IVR service (with information 
also stored in databases 101/102) using various telephones. 
This passage teaches nothing regarding supporting remotely 
hosted phone application development. 

The Office Action further cites col. 8, lines 1-17 as 
teaching the claim limitation "responsive to receiving the 
URL..." . However, this passage merely teaches making the 
connections shown in Fig. 5 and monitoring the automated 
translation of the web menu structure to the IVR menu structure. 
This passage teaches nothing regarding sending the first message 
to the phone application platform in response to receiving the 
URI . 

The Office Action further cites col. 8, lines 18-34 as 
teaching the claim limitation "upon receiving a request../ 7 . 
However, the web menu structure provided on computer 84 cannot 
be characterized as a flow of execution for the calls to the 
telephone number for the phone application on the phone 
application platform. 

Based on the above reasons, Applicants request 
reconsideration and withdrawal of the rejection of Claim 15. 
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Claims 16-22 and 24-27 depend from Claim 15 and therefore 
are patentable for at least the reasons presented for Claim 15. 
Based on those reasons, Applicants also request reconsideration 
and withdrawal of the rejection of Claims 16-22 and 24-27. 

Claim 28, as amended, now recites in part: 

responsive to receiving a telephone call via 
the telephone number, executing the phone 
application code, presenting an audio output over 
the telephone interface, and presenting a call 
flow to the remote computer over the network 
interface, the call flow tracking a flow of 
execution for the telephone call. 

Applicants respectfully submit that Claim 28 is patentable 
for substantially the same reasons presented for Claim 1. 
Therefore, Applicants request reconsideration and withdrawal of 
the rejection of Claim 28. 

Claim 29, as amended, now recites in part: 

means for presenting to the second computer 
a call flow generated by calls to the telephone 
number for the phone application on the phone 
application platform upon receiving a request 
from the computer system, the call flow tracking 
a flow of execution for the calls. 

Applicants respectfully submit that Claim 29 is patentable 
for substantially the same reasons presented for Claim 1. 
Therefore, Applicants request reconsideration and withdrawal of 
the rejection of Claim 29. 

Burg, House, And Computing Fail To Render Obvious Claims 3 And 8 

Claims 3 and 8 depend from Claim 1 and therefore are 
patentable for at least the reasons presented for Claim 1. 
Computing merely defines a trace program. Therefore, Computing 
fails to remedy the deficiencies of Burg and House. Based on 
these reasons, Applicants respectfully submit that the cited 
references fail to disclose or suggest Claims 3 and 8. 
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Burg, House, And Curreri Fail To Render Obvious Claim 23 

Claim 23 depends from Claim 15 and therefore is patentable 
for at least the reasons presented for Claim 15. Curreri fails 
to remedy the deficiencies of Burg and House. Specifically, 
Curreri teaches a debugger that retrieves data from a mapping 
data structure. Col. 12, lines 62-63. This mapping data 
structure includes the data identifying data change point 
instructions. Col. 12, lines 63-64. The debugger uses that 
data to control execution of a program such that, in response to 
a user command, execution of the program is stopped at a data 
change point instruction. Col. 12, lines 65-67. Based on 
these reasons, Applicants respectfully submit that the cited 
references fail to disclose or suggest Claim 23 . 
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CONCLUSION 

Claims 1-29 are pending in the present Application. 
Applicants respectfully request allowance of these claims. 

If there are any questions, please telephone the 
undersigned at 40 8-451-5907 to expedite prosecution of this 
case. /0 XP ^\ 





Respectfully submitted, 



Customer No.: 24488 



Attorney for Applicant 
Reg. No. 35,537 
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